Initiatives such as in Non-Patent Literature 1 and Non-Patent Literature 2 describe how to start-up a device in an assured and trusted fashion. These methods have been thoroughly reviewed to ensure that trust and security is maintained throughout the boot process, so provide a useful baseline for those wanting to implement a device that can boot securely. A key component of this secure boot process is a Reference Integrity Metrics (RIM) Certificate. This is a signed structure that defines what the current expected platform state should be, represented by a hash of a set of Platform Configuration Registers (PCRs), which themselves contain known, publically defined hash values. These PCRs act as integrity measurements that may be recorded in RIM Certificates to define an expected machine state. In addition, the RIM Certificate also specifies a PCR to be extended if the current state is verified. This extend process takes a specified PCR and calculates a new hash value based on the previous PCR value concatenated with a new known value defined within the RIM Certificate. A typical secure boot sequence as defined by the Trusted Computing Group (TCG) starts with the initialization and self-verification of the core components such as the Root-of-Trust for Verification (RTV) and the Root-of-Trust for Measurement (RTM) (the RTV+RTM), the Mobile Trusted Module (MTM) itself and associated core MTM interface components. Next, additional components that support other parts of the firmware are started in a trusted fashion, for example, each of them is verified on their starting by another component having been booted before them. And finally the operating system runs to provide a secure and trusted path for client applications to access MTM services.
However, the specifications are rigid, providing only a single control path though the boot process that results either in complete success or complete failure. In other words, if boot process of one component is failed, all of the other components cannot be used even if their own boot processes resulted in success.
Furthermore, the TCG specifications provide facilities for auditing, recognising that portable devices such as mobile phones have limited resources. Although they define these auditing features are optional with an MTM, but this makes problems shown below. As described above, although this feature is merely an option, a failure in the boot process of this feature makes all components of the mobile phone unable to be used. Furthermore, although this feature is not needed to be implemented (because it is an option), the verification becomes always failed without implementing this feature. This makes it harder for other processes to detect why or where there was a failure in the boot process. Furthermore, a device manufacturer may wish to offer certain trusted components as options.
Here, optional components mean, for example, system or application software which can be enabled after the user enters into an additional contract. Here, “enabled (or active)” means changing a state of the application software to a state the user can run the application software. Unless the software is enabled, the use cannot use the system or application software, even if the system or application software itself is pre-installed in the machine or downloaded from a server.
As described above, whether an optional component is enabled or not may be determined by each user's decision. So, the server for sending updated RIM certificates to the machine would to know which components are enabled for each machine in order to send updated certificates corresponding to the enabled components.
Additionally, in many markets there are legal requirements upon service providers to allow users to make emergency calls even from mobile phones that do not have a current service contract or are outside of areas where they have a current service contract. On a phone equipped with an MTM, revocation of certificates or corruption of non-critical components result in a phone that may fail to operate at all, so cannot meet this legal requirement.
In Patent Literature 1, a verified boot method with optional components is disclosed, but the optional components are implemented according to explicit switches; there is no consideration for how to handle an error occurring when handling an optional component such as component program file corruption or hardware initialization failure.
In Patent Literature 2, a verified boot method with components that may fail verification is disclosed, but it does not teach how to solve this problem.
What is needed, therefore, is a method that will support optional components within the context of a secure boot as defined by the TCG Mobile Phone Working Group, and will still operate in a reduced functionality manner even though some RIM Certificates (RIM Certs) are revoked or components are disabled or not functioning, and that will allow an easier, less resource-heavy method of determining the state of a MTM after secure boot finishes.
What is further needed, therefore, is a machine and a server for updating the components that are enabled or disabled without the need for making a customized set of updated certificates available for each machine.